DAS API architecture

The project is based on the Clean Architecture Principles

The project's structure is a reflection of the following clean architecture principles:

• Framework Independence: The architecture is built to be independent of any specific framework or library.
• Testability: Business rules can be independently tested without UI, Database, or external interfaces.
• UI Independence: Changes in the UI do not impact the core application logic.
• Database Independence: Business logic is not tightly coupled with the database technology.
• External Agency Independence: Business rules are unaware of anything outside their scope.

Project structure

• entities. Contains business models that represent the domain and are used across various layers of the application.
• interface. Stores traits that define public-facing interfaces, segregating the layers and ensuring loose coupling.
• usecase. The domain-centric heart of the application, containing use cases that encapsulate business rules.
• grpc. Houses gRPC service definitions and their implementation.
• digital_asset_types. A legacy workspace with models and API definitions from the project's previous versions.
• nft_injester. meant for API implementation; it currently includes additional logic that should be refactored in line with clean architecture.
• data layer spread across
  • rocks-db. Primary data source for the application. It contains the implementation of the database client and should be used for all persistent data storage, retrieval, and data manipulations.
  • postgre-client. Secondary data source used exclusively for search indexes. The implementation here should focus on indexing and search-related operations to optimize query performance. Potentially this may be replaced with the SQLite to allow a self-contained and easy to deploy solution.